Physical web beacon, client and proxy

ABSTRACT

The physical web is an interesting development in networking technology. A beacon may broadcast beacon data and, if desired, a data payload. In various embodiments, a proxy may receive contact from a mobile machine that came into contact with a beacon and received data bringing the mobile machine to the proxy. The proxy may dynamically select a redirection for the mobile machine based on a variety of considerations discussed herein. The proxy may also employ cryptographic and context analysis to the contact from the mobile device to determine if the redirection should happen. And the proxy may review contacts originating from various beacons to determine whether the contacts, or lack thereof, from a beacon suggests the beacon needs to be investigated for failure, error, or tampering with it or its environment.

TECHNICAL FIELD

The present disclosure relates to the physical web, and moreparticularly, to managing physical web beacons and providing a dynamicproxy for resolving and optionally authenticating beacon data.

BACKGROUND AND DESCRIPTION OF RELATED ART

The proliferation of Internet enabled devices, the Internet of Things(IoT) and and other technologies has enabled interactive communicationbetween known and sometimes unknown devices. The interactions may allowfor a variety of transactions, such as purchase of goods, receipt ofinformation, or other communicative event over a possibly temporarycommunication path formed between two devices. A relatively recentconcept is that of the physical web. This concept ties together mobilemachines, such as cell phones, tablets and other portable electronics toIoT environments, hardware beacons, or interoperate in other networkingsituations.

See for example a discussion of the physical web at Uniform ResourceLocator (URL) Google.github.io/physical-web, which notes at the time offiling this application the “Physical Web enables you to see a list ofURLs being broadcast by objects in the environment around you. Anyobject can be embedded with a Bluetooth Low Energy (BLE) beacon, whichis a low powered, battery efficient device that broadcasts content overbluetooth. Beacons that support the Eddystone” (see, e.g., Internet URLgithub.com/google/eddystone) “protocol specification can broadcast URLs.Services on your device . . . can scan for and display these URLs afterpassing them through a proxy.” URLs may not only indicate an Internetlocation to which a mobile machine could be directed, but it may alsoinclude identification of the machine, e.g., a URL may be formatted withembedded variables such as an id: “exampleserver.com/?id=12345”.

With the likely to be billions of IoT and physical web devices expectedto be out in the world, device management becomes an issue. In addition,because the Eddystone protocol provides a short (e.g., 17) bytes for theURL packet, intelligent URL handling and smart proxy processing willbecome increasingly important as the physical web becomes moreprevalent.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be readily understood by the following detaileddescription in conjunction with the accompanying drawings. To facilitatethis description, like reference numerals designate like structuralelements. Embodiments are illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings.

FIG. 1 illustrates an exemplary environment 100.

FIG. 2 illustrates an exemplary environment 200.

FIG. 3 illustrates an exemplary Uniform Resource Locator (URL) 300.

FIG. 4 illustrates an exemplary environment 400.

FIG. 5 illustrates an exemplary environment 500.

FIG. 6 illustrates an exemplary computer device 600 that may employ theapparatuses and/or methods described herein.

FIG. 7 illustrates an exemplary computer-readable storage medium 700.

FIG. 8 illustrates a block diagram of a network 800 illustratingcommunications among a number of IoT devices, according to an example;and

FIG. 9 illustrates a block diagram for an example IoT processing systemarchitecture 900 upon which any one or more of the techniques (e.g.,operations, processes, methods, and methodologies) discussed herein maybe performed, according to an example.

FIG. 10 illustrates a block diagram of a network illustratingcommunications among a number of IoT devices, according to an example.

FIG. 11 illustrates a block diagram for an example IoT processing systemarchitecture upon which any one or more of the techniques (e.g.,operations, processes, methods, and methodologies) discussed herein maybe performed, according to an example.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings which form a part hereof wherein like numeralsdesignate like parts throughout, and in which is shown by way ofillustration embodiments that may be practiced. It is to be understoodthat other embodiments may be utilized and structural or logical changesmay be made without departing from the scope of the present disclosure.Therefore, the following detailed description is not to be taken in alimiting sense, and the scope of embodiments is defined by the appendedclaims and their equivalents. Alternate embodiments of the presentdisclosure and their equivalents may be devised without parting from thespirit or scope of the present disclosure. It should be noted that likeelements disclosed below are indicated by like reference numbers in thedrawings.

Various operations may be described as multiple discrete actions oroperations in turn, in a manner that is most helpful in understandingthe claimed subject matter. However, the order of description should notbe construed as to imply that these operations are necessarily orderdependent. In particular, these operations do not have to be performedin the order of presentation. Operations described may be performed in adifferent order than the described embodiment. Various additionaloperations may be performed and/or described operations may be omittedin additional embodiments. For the purposes of the present disclosure,the phrase “A and/or B” means (A), (B), or (A and B). For the purposesof the present disclosure, the phrase “A, B, and/or C” means (A), (B),(C), (A and B), (A and C), (B and C), or (A, B and C). The descriptionmay use the phrases “in an embodiment,” or “in embodiments,” which mayeach refer to one or more of the same or different embodiments.Furthermore, the terms “comprising,” “including,” “having,” and thelike, as used with respect to embodiments of the present disclosure, areconsidered synonymous.

As used herein, the term “circuitry” or “circuit” may refer to, be partof, or include an Application Specific Integrated Circuit (ASIC), anelectronic circuit, a processor (shared, dedicated, or group) and/ormemory (shared, dedicated, or group) that execute one or more softwareor firmware programs, a combinational logic circuit, processor,microprocessor, programmable gate array (PGA), field programmable gatearray (FPGA), digital signal processor (DSP) and/or other suitablecomponents that provide the described functionality. Note while thisdisclosure may refer to a processor in the singular, this is forexpository convenience only, and one skilled in the art will appreciatemultiple processors, processors with multiple cores, virtual processors,etc., may be employed to perform the disclosed embodiments.

As noted above, technology such as the Physical Web is a relatively newand developing technology that may be supported by mobile machines suchas cellphones, tablets, computers, Internet of Things (IoT) devices, orany mobile machine or device that may be physically moving, includingthose moving as being part of a transportation device.

FIG. 1 illustrates an exemplary environment 100 in which shown are abeacon 102 attached to a structure 104, which for exemplary purposes isa shelter such as that may be used for obtaining transportation, e.g., abus stop, taxi stand, private carriage service, ticketing area for anevent, ticketing area for transportation, etc. The beacon, as notedabove broadcasts a signal 106 that may be in accord with anycommunication protocol. If for expository convenience we assume thebeacon is a Physical Web beacon, then the beacon may be broadcasting inaccord with the Eddystone signaling technique. It will be appreciatedthat Eddystone is presented as one communication example but othercommunication technologies or network discovery techniques may beapplied to interconnect different devices, such as multicast Domain NameSystem (mDNS) (see, e.g., Internet Engineering Task Force (IETF) RequestFor Comments (RFC) 6762), Universal Plug and Play (uPnP) over WiFi™. Abroadcasted signal may be picked up by a mobile machine 108 that isproximate to the structure, such as by a mobile telephone or other smartdevice, tablet, phablet, computer, notebook, IoT device, etc. It will beappreciated although the mobile machine is illustrated as carried by aperson 110, it is not necessary for a person to be present and insteadthe mobile machine may be part of another machine that comes intoproximity of the beacon. For example the mobile device may be part of atransportation device such as a bus, train, taxi, private carriage,etc., that comes into range of the beacon transmission.

In the illustrated embodiment, the broadcast 106 contains beacon data112, which is simply data that is broadcasted by the beacon, or in somecircumstances (not illustrated), otherwise associated with the beacon.By broadcasting with a low-power technology such as lower powerBluetooth (BLE) it is possible to both minimize power requirements of abeacon if the beacon is battery powered, as well as to assist withensuring a recipient mobile machine 108 (or machines) are proximate tothe beacon. Proximity becomes more important when, for example, theinformation provided by or associated with the beacon is relevant tothat beacon's specific location. If the beacon is associated with busstops, it is helpful to ensure that bus ticket pricing informationassociated with a beacon broadcast is constrained to devices near thatbus stop. In some embodiments, the beacon data contains a shortenedUniform Resource Locator (URL) to direct the mobile machine to aspecific location on a network 114, such as a proxy server 116 that isconfigured to interact further with the mobile machine. A shortened URLservice may be used that provides a unique URL for a beacon to allow,simply based on URL access, to track accesses to a particular beacon(1:1 correspondence between beacon and URL) or set of beacons sharing aURL (many-to-one correspondence). Even if every beacon is assigned aunique URL to broadcast, the proxy 116 may classify or otherwise groupbeacons and redirect mobile machines to a same or similar resource onthe network. There may be a 1:1 relationship between URLs and beacons,or groupings of beacons may be associated with a particular URL. In oneembodiment the server can dynamically disable (e.g., not redirect) aparticular URL, such as if a temporary beacon is no longer needed, or inhigh-traffic environments, the proxy may distribute a heavily loadeddevice to different servers to allow load-balancing network resources.

In some embodiments, broadcasted beacon data is automatically received206. For example, in one embodiment, a Notifications feature that iscurrently supported by a variety of browsers and platforms such asGoogle Chrome™, Android Platform™, Safari® and iOS are currentlysupporting Notifications. In a bus stop example, when a person wants tocatch a bus, and gets to the stop, their mobile machine wouldautomatically receive the beacon data, e.g., in one embodiment anEddystone type of beacon placed at the bus stop. When their mobilemachine is in range of the beacon, they may receive a notification thatmay direct the user of the mobile machine to a short branded URLlocation. This URL in turn may resolve to a server that tracks thelocation of the bus, the time the bus should arrive at the specific buststop, and allow the user to purchase a ride. This may occur all withouta user ever having to look up a URL, install an application, or evenidentify themselves or their location on a website.

It will be appreciated that the mobile machine may establish acommunication path 118 with the proxy 116 to the network 114 by anycommunication technology, such as over a cellular data network, Wi-Fi™(a standard by the Wi-Fi Alliance for networking based on the Instituteof Electrical and Electronics Engineers (IEEE) 802.11 standards, orother short-range or long-rage radio (or even wired) communicationtechnology including those discussed further below with respect to FIG.6. The mobile machine may use the shortened URL received in the proxydata, or it may use a different URL corresponding to the beacon data'sshortened URL but that may have been altered by the mobile machine.

It will be further appreciated communication between a beacon 102 and amobile machine 108 may be bi-directional, so that the beacon may triggera communication session by broadcasting the beacon data 112 and themobile device may then respond to it and perhaps elicit customized datafrom the beacon. This could be used, for example, to provide a generalURL in the broadcast to which the mobile machine may identify itself asa VIP device and thus the beacon may then provide a VIP broadcast forthat mobile machine. However, this may raise security concerns (as wellas cost by making the beacons more complex) as it would be possible forbeacons to start tracking the movement of the mobile machine. Since someprotocols require the beacon to broadcast its data using HTTPS (a securehypertext transport protocol (HTTP)), such as the Google Chrome physicalweb support and Android Nearby Notifications, a the beacon may beconfigured with an antenna or other communication option. The mobilemachine may then establish a connection (possibly anonymous) back to thebeacon with a “VIP” HTTPS certificate which indicates to the beacon toprovide VIP beacon data. Alternatively, presuming the beacon isconfigured to be broadcast only, VIP recognition may instead bedetermined and handled by the Proxy 116.

Note that there is the risk of a rogue beacon 122 being illicitlyinserted into an environment, such as the structure 104. Such a devicemay intermittently steal connections from a mobile machine 108 enteringthe area, thus providing the rogue an opportunity to perform illicitoperations, e.g., inject viruses into the mobile machine, engage themachine to obtain financial information, etc. It will be appreciated therogue could perform an illicit act and then attempt to redirect themobile machine to the proxy 116 as if nothing untoward had occurred. Aswill be discussed below with respect to FIG. 2 various options areavailable for minimizing such a threat.

FIG. 2 illustrates an exemplary environment 200 illustrating a mobilemachine engaging with a beacon. In this embodiment, as discussed above amobile machine comes 202 into range of a beacon broadcasting its beacondata. As noted above, there may be a risk of a rogue beacon illicitlyinserted into an environment. In an effort to prevent this, it will beappreciated the beacon data may incorporate security provisions such asa rotating token, e.g., a rolling code generated by the GoogleAuthenticator and similar technologies, or some or all of beacon databroadcast by the beacon may be encrypted.

In one embodiment, a mobile device may need to synchronize 204 with thebeacon to enable authenticating the beacon. This may be unnecessary ifthe mobile machine has already loaded an app or gone to a webpage thatfacilitates getting security credentials. If credentials are needed,this may be accomplished in a variety of ways including the mobilemachine scanning a barcode, Quick Response (QR) code, or other markingon the beacon to direct the mobile machine to the credentials. Or, thebeacon (or system of beacons such as by a transit authority) may belooked up in a known or trusted registry to help establishsynchronization. Or, a web page (which may be identified on the beacon)may be accessed to assist with synchronization, including downloadingsecurity software, security certificates, tokens, profiles, or the like.After synchronizing with the beacon, if it was needed, a mobile devicemay then receive 206 the beacon data broadcast by the beacon.

In one embodiment the beacon may incorporate identifying characteristicsof the contacting mobile machine in the beacon data, such as storing thenetwork interface (NIC) machine access control (MAC) ID, which while notunique, it may be considered operationally unique within the shorttimespan in which beacon-related communication occurs. The identifyingcharacteristic may be encoded, hashed, or otherwise cryptographicallysecured to minimize ability alter the information. By embedding thisinformation, additional security may be realized since if a rogue deviceattempts to sit in-between the beacon and the proxy, the proxy will beable to determine a connecting mobile machine does not have the sameoperationally unique identifying characteristics that was recorded bythe beacon.

It will be understood a beacon might not employ security measures, butassuming synchronizing 204, a following operation is to validate 208 thereceived beacon data. If a token-based approach is implemented, themobile machine may validate by checking what the expected rotating tokenshould be and confirm this token is present in the beacon data. It willbe appreciated the use of the token is one form of a cryptographictechnique that may be used to secure communication, but others may beused, such as a public key infrastructure (PKI) environment where aprivate key known to the beacon is used to encrypt and/or encode some orall of the beacon data being broadcast. The mobile machine may acquire apublic key for the beacon, such as by way of a known key server. In someenvironments, such as within a large private structure, such as a largewarehouse or large store, in a shipping center/“mall”, in a citytransportation system, etc., the environment may provide a key for allof its beacons by way of a known private key server or by way of apublic key server. For example in the city example, a commuter's mobilemachine may obtain a key to authenticate the beacon in advance, or themobile machine may acquire the key when it comes into contact with thebeacon such as by scanning a code on the beacon as discussed above forsynchronizing 204.

The mobile device may receive 206 the beacon data, and assuming use ofsome cryptographic verification technique, e.g., rolling token, PKI, orother validation technique, the mobile machine may validate 208 thereceived beacon data. In one embodiment, instead of an authenticatortype of token, instead a sequence number is associated with a URL ordata payload (e.g., Eddystone and similar technologies provide for asmall data payload along with the URL). Since the proxy or proxies(there may be multiple servers to handle beacon-initiated contacts maytrack contact, seeing an incorrect/invalid sequence of numbers maytrigger and error/need to investigate to see if a beacon ismalfunctioning or compromised. In another embodiment, rolling clockwindows (time) values are associated with a URL or data payload. In oneembodiment, the clock value may be hashed in accord with a cryptosystemto verify them, and once received the clock values may be used toidentify communication delay, which may in turn help identifyinterference with beacon operation.

In one embodiment, for simplicity, the beacon data caters to a singleaction, e.g., the mobile device is consuming a piece of content toperform an action, which facilitates both a simple beacon design, andfacilitates a broadcast only arrangement. It will be appreciated thedata being broadcast may be arbitrary. In the illustrated embodiment thebeacon data includes a URL. It will be appreciated the beacon may onlybe transmitting a URL, or it may be broadcasting data including a URL.After receiving 206 the beacon data the mobile machine may thenrecognize 210 the URL within the beacon data. In one embodiment, insteadof simply using an existing shortened URL creation scheme, insteadillustrated embodiments provide for dynamic URL destinations whichtypical short URLs do not provide.

In one embodiment, there may also be an expected duration ofcommunication associated with a URL, where if the duration is notcorrect then an error alert may be generated. For example if a beacon isused by a public transportation system, a request to the URL would beexpected at least once during the duration between one stop and the nextstop. If the proxy server does not receive a request with the designatedbeacon data that identifies the specific beacon of interest during thatduration, it may mean there is a problem and in response a durationalert may be issued. In some embodiments, beacons are given easilyrecognizable branded shortened URLs that may assist with security. Auser of the mobile machine may be able to see the URL and, if directedto an incorrect location, may realize that the beacon and/or the proxymay be compromised. can also provide for branded short URL which isimportant for security. It would also provide for the capability toselectively disable specific branded URL for security reasons. It willbe appreciated the URL may be arbitrarily formatted. In someembodiments, the protocol used by the beacon may limit the size of theURL (see, e.g., Eddystone limitations discussed above in paragraph 4and/or any payload that may be associated with it. Thus is someembodiments, a shortened URL may be used to minimize transmissionrequirements, as well as to either provide for obfuscating the target ofthe broadcasted URL, if target-privacy is desired, or to simplify a userrecognition that the URL is authentic.

For example, FIG. 3 illustrates an exemplary Uniform Resource Locator(URL) 300 that may be broadcasted. In this example, assume the city ofPhoenix Arizona uses shortened URLs for its beacons. As illustrated, theformat of the URL could be a combination of a beaconID 302, with a citydomain name PHX.gov 304. While seeing PHX.gov would assist a user inknowing the beacon is a valid city beacon since PHX.gov is presumablyonly accessible to an authorized city resource, it is not guaranteedthat the user can see it, e.g., the mobile machine interface might notpresent, or may not be able to present (e.g., some IoT devices may havelimited or simply lack a display), the broadcasted URL to the user. Oneway to assist with validating the beacon, as discussed above, the URLmay include a cryptographic component 306 for validating beacon data.Please note that for presentation convenience, the illustrated URL maycontain more characters than may be supported by a given beaconbroadcast protocol. In an implementation of the URL, the “beaconID” 302may be replaced with a shorter ID number. Similarly, thecryptographicData 306 component may be replaced with a shorter tokenvalue, hash value, or as noted above the entire URL 300 may be encodedwith a PKI and hence unreadable without use of a corresponding publickey associated with the broadcasting beacon.

Continuing again with FIG. 2, after recognizing 210 the URL, the mobilemachine loads 212 the URL. In the illustrated embodiments, loading theURL directs the mobile machine to a proxy, see, e.g., FIG. 1 item 116.Although this figure is directed primarily to operations from theperspective of a mobile machine, it will be appreciated on contactingthe proxy, the proxy may review 214 the contact from the mobile machine,perform data tracking, check for security issues, and the like. Themobile device may receive 216 a redirection from the proxy that may bebased on a variety of factors. That is, rather than a beacon sending themobile machine to a specific network location, such as an Internet webaddress, instead the mobile machine is directed to the proxy which can,depending on various considerations, redirect the mobile machine to adynamically generated destination. When this dynamic redirection isreceived 216, the mobile machine may load 218 the identified resourceaccordingly.

The ability to change dynamically where a beacon URL directs a mobilemachine provides for opportunities to provide dynamic servicesresponsive to the location of the beacon. For example, if the beacon hasa custom shortened URL identifying that beacon, and the beacon is amobile beacon, e.g., it is relocated periodically, or perhaps installedin a moving vehicle/transportation device, then based on some criteriasuch as its current location, time of day, congestion, crowddemographics, event schedules, multi-user/multi-player groups proximateto the beacon, etc. the proxy may dynamically change the destination forthe URL to be relevant to a current location. Unlike conventionaldynamic URL redirection schemes and services, in the illustratedembodiment, the contact review 214 and proxy analysis allows not onlyconventional tracking of how many times a particular URL is accessed(such as to gauge popularity of a beacon), but also to track where themobile machine was directed from. This can be determined in a variety ofways, including based on the URL used to access the proxy, data embeddedwithin the URL or as a variable in the URL, or in a beacon payload (ifany).

In the review 214 the proxy may also apply heuristics to help determineif a particular beacon is operating correctly. For example, use profilescan be built that can allow a proxy to predict use patterns for a beaconand if there is a significant change in expected contacts arising out ofusing that beacon, it may mean a beacon has broken and need replaced. Aproxy may know the location and origin of a URL (e.g., when theshortened URL has a 1:1 mapping to the beacon, has an embedded ID, orother identifying characteristic in the beacon data), and therefore itmay provide custom alerts to a repair team when a particular URL is notbeing accessed. For example, if no accesses are being generated by abeacon at a movie theater, or there is an unexpected drop in accesses,then the beacon may be failing or have failed. Alternatively, asdiscussed above, a rogue beacon may have been illicitly employed, andassuming the rogue can mimic a beacon and trick a mobile device intousing it, this may cause a drop in contact from the legitimate beacon.In this scenario, loss of legitimate contact can be recognized andtrigger a repair and/or investigation that will reveal a rogueinfluence.

It will be appreciated that the received 216 redirection may bedynamically generated based on any criteria of interest. For example, ifthe beacon is associated with a sporting arena, the proxy may beconfigured to understand that the arena beacon is presenting a showtoday from Organization A (e.g., a soccer match), and tomorrow fromOrganization B (a rugby game), and if a mobile machine comes intocontact with the beacon today, the proxy redirects the mobile machine toinformation, or ticketing options, or the like for Organization A. Butwere the mobile machine to come into contact with the beacon tomorrow,it would instead be redirected to material for Organization B.Similarly, for a bus station, the proxy may redirect based on the timeof day, e.g., peak hours cost more, off-peak less. Or, there could be afare sale, or holiday season for which rates are reduced. Rates might beeliminated, for example, on a holiday (or day after) a holidayassociated with drinking. Certain days of the week might be deemed free,or a flat rate used for a day when an all-day event is occurring nearby.

Health, environment or safety concerns can also be automatically handledby the proxy. For example, the proxy may receive information from othersources that air quality is poor and this may result in a dynamic changeto where a mobile device is redirected. Instead of getting a fareinstead a warning may be presented with then the option to purchase aticket, or simply be informed the fare is temporarily free to encouragepeople to avoid travel outdoors. It will be appreciated the criteria isendless and needs to only be set in the proxy as that proxy can identifythe origin beacon and redirect a mobile machine accordingly. Safety mayalso be a concern, and in the event of an emergency, a proxy may directpeople to resources to assist with the emergency based on the locationfrom which the mobile machine is making contact. As with other examplesdiscussed herein, pricing may be adjusted to accommodate circumstances.

As will be understood by one skilled in the art, private beacons may beemployed. For example, large retail chains may purchase proxy servers,and configure them to respond to beacons within their stores. Thisallows any desired incentive within the store based on any criteriadesired, such as time in store, movement pattern within the store,cascading offers to entice paired product purchases, or the like. Forexample, a store could start a sale and then start redirecting mobilemachines to a page that says buy Product A at one price and get ProductB at a discount or perhaps free. Prices in the store could also changeover time, be based on position in the store (e.g., to attract attentionto unpopular sections), be based on past purchase and/or activityhistory (assuming the mobile machine has established a known identitywith the store), incorporate any combination of these, or otherrationale.

FIG. 4 illustrates an exemplary environment 400 from the perspective ofthe beacon. While most activity occurs with the proxy and mobile device,there are embodiments that may focus on the beacon. In the illustratedembodiment it is assumed the beacon is computing 402 its cryptographicinfo, such as a rolling token, or other encoding as needed forbroadcasting 404 to a mobile machine (if any are present) the beacon'sbeacon data.

After broadcasting, a typical beacon might simply loop back to computingnew 402 (if needed) cryptographic information. However, in theillustrated embodiment, the beacon instead tests to see if 406 it isreceiving an incoming connection. If yes then the beacon starts toidentify the nature of the incoming connection. It will be appreciated avariety of maintenance and/or custom operating modes may be used. Forexample, a test may be made to determine if 408 the beacon is beingasked to enter an update mode 410. It will be appreciated if a beacon isconfigured with a long lasting power source, is wired to power, hassolar power, etc., then it would be convenient to not have to travel toa beacon simply to update it. Reasons for updating could be firmwareupdating/optimizing, replacing cryptographic functions and/or associatedkeys (such as may be required if keys are stolen), etc. Instead, in oneembodiment a large scale broadcast is made to a region to instructbeacons to update, and this is performed in the update mode. In analternate embodiment, other equipment that is known to travel pastbeacons may be used to update them opportunistically.

For example, since beacons at bus stops will regularly have buses passby, the bus may have equipment for calling out to beacons as the bus isstopping at a bus stop, and while near the beacon the bus may trigger anupdate. Or, in an arena, a drone or other mobile device may be taskedwith coming into range of a beacon and updating it. It will beappreciated that while wireless communication is convenient,communication may be by way of a physical connection. In one embodiment,the physical communication is through induction, e.g., in the droneexample the drone might land on the beacon/beacon's surroundingstructure and inductively communicate an update. Regardless of thecommunication technique employed, while communicating, a beacon may bequeried for statistics about its operation, such as the number of timesthe beacon has had operational trouble, power failures, or other indiciaof impending failure. In addition, any interactive sessions with thebeacon may be logged.

Another activity as discussed above is engaging in a VIP mode. While itmay be appreciated the proxy may dynamically redirect a mobile devicebased on its characteristics (e.g., all Brand X mobile phones get aspecial discount from a Brand X beacon), or identity. Therefore, anothertest is to determine if 412 VIP is desired, and if so, then the beaconcan take appropriate action, such as to broadcast 414 a VIP beacon datathat may direct the mobile machine to a special proxy or other networklocation. The beacon may take other action or interaction (notillustrated) if desired, including providing the mobile machine withspecial credentials for future communication with the beacon or proxy.It will be appreciated if a mobile machine has a VIP certificate, sincea beacon may be broadcasting with a HTTPS certificate and hencecommunicating using a public certificate, the mobile machine maydisregard that public-user certificate and instead contact the beaconwith a private certificate to trigger a VIP response such as tobroadcast 414 the VIP beacon data. It will be appreciated these aresimply two exemplary interactive engagements with a beacon, and that thebeacon may continue to check if 416 other actions (not illustrated),such as interactive password based access, are to be performed, and ifso the beacon performs 418 these actions. After all activity has beenreviewed, processing may loop 420 back to updating the cryptographicinformation as needed.

FIG. 5 illustrates an exemplary environment 500 illustratingcommunication from the perspective of a proxy, and roughly correspondingto FIG. 2 items 214-218. For illustrative purposes it is assumed thatthe proxy is a physical web proxy (see, e.g., FIG. 1 item 116), but itwill be appreciated that other types of proxies and/or networkingdevices may perform the techniques discussed herein. As illustrated, theproxy is assumed to have one or more communication paths, each of whichmay maintain one or more communication sessions with multiple machinesutilizing the proxy. The proxy to be communicatively coupled over afirst communication path with a mobile machine, such as by way of a datanetwork which may include the Internet. The mobile machine may be atleast temporarily be or to communicate with a beacon broadcasting beacondata to the mobile machine (see, e.g., the FIG. 2 discussion) over asecond communication path, which may be by way of Bluetooth Low Energy(BLE) as discussed above, or by way of other communication technology.It will be appreciated at time progresses different communicationtechnology may be implemented and used without departing from theapplicability of the teachings herein.

After receiving 502 mobile data from a mobile machine, the proxy mayvalidate 504 the received data. As discussed above (See, e.g., FIG. 2item 208), various cryptographic and/or other security features may beemployed to ensure that the contact from the mobile machine is valid.This can help rule out mistaken access of the proxy, rogue beaconsattempting to manipulate the proxy, etc. Thus, for example, the proxymay perform a cryptographic signature verification, or decryption ofsome or all of the mobile data as needed. Alternatively, the proxy mightcheck an embedded or associated sequence number in the mobile data tovalidate it is the correct type of sequence, or in an expected valuerange, etc. If 506 validation suggests the contact is invalid, then thecontact may be rejected 508 and/or an error handler invoked.

If 506 the mobile data is valid, then a context analyzer may check 510the context for the contact. Some embodiments may, in addition to othersecurity checking, sanity check the contact to make sure it isreasonable to have received the contact. For example, the proxy mayreview the timing of the contact, so, for example, if the proxy knowsthe beacon is associated with a location that is closed, then thecontact may be considered suspicious and action taken to investigateand/or otherwise address it. In addition to time of day, the proxy mayalso look to frequency of contact, e.g., how many times a particularmobile machine is seen by a proxy, or how many contacts appear to beoriginated by a specific beacon, and if the contact falls outsideexpectations then this can trigger investigation for beaconerror/failure, rogue beacons or machines attempting to compromise theenvironment, etc. Still further, the proxy may look to the type of themobile machine in comparison to the service offered by the beacon, andverify that it makes sense for the mobile device to be contacting thebeacon. It will be appreciated that these are merely exemplary contextsto consider and that others may be used. If 510 the context is notdetermined to be valid, then the contact may be rejected 508 and/or anerror handler invoked.

However, if 506 the mobile data is valid, and if 510 the context isvalid, then the proxy may determine a redirection target. As discussedabove, various considerations may factor into selecting the redirectiontarget, such as the context, calendared events (either associated withthe mobile device, or public holidays and/or events), some combinationof these or based on other criteria, including proximity of any of theseto the beacon giving rise to the contact with the proxy. Based on suchconsiderations, the proxy determines 512 the redirection target. It willbe appreciated that the proxy may maintain, or have access to, a datastore (such as a database, cloud-based storage, etc.) to one or moretargets. Assuming the proxy has access to multiple redirection targets,it will be appreciated the proxy may dynamically select a target basedon the context and other considerations associated with the proxy and/orcharacteristics of the mobile machine and/or a status (e.g., VIP)associated with the mobile machine.

Once a redirection target is determined 512 the redirection target maybe sent 514 to the mobile machine for its processing. It will beappreciated that over time different technologies may be employed toidentify the proxy to which a mobile machine should be directed, whichin turn may dynamically redirect the mobile machine to a particularnetwork resource. In one embodiment, it is assumed the beacon broadcastsa URL that the mobile machine can receive and access to be directed tothe proxy. However, in another embodiment, the beacon instead broadcastsdata that may be interpreted by the mobile machine, which may alsoinclude compiling, executing, and/or looking up data that in turn allowsthe mobile machine to access the proxy. Therefore in selectedembodiments there is an idea of a correspondence between data broadcastby a beacon and the URL (or other data form subsequently developed toreplace URLs) used by the mobile machine to contact the proxy. In thesimplest case, the correspondence is direct, e.g., the beacon broadcastsa URL and that URL is directly used by the mobile machine to access theproxy. In another direct correspondence type of case, the beacon dataincludes a URL that is extracted from the beacon data by a mobilemachine and used by the mobile machine to access the proxy. The variousillustrated components, e.g., beacon, mobile machine, and/or proxy, maybe configured to confirm a correspondence between beacon data and mobiledata.

FIG. 6 illustrates an exemplary computer device 600 that may employ theapparatuses and/or methods described herein, in accordance with variousembodiments. As shown, computer device 600 may include a number ofcomponents, such as one or more processor(s) 602 (one shown) and atleast one communication chip(s) 604. In various embodiments, the one ormore processor(s) 602 each may include one or more processor cores. Invarious embodiments, the at least one communication chip 604 may bephysically and electrically coupled to the one or more processor(s) 602.In further implementations, the communication chip(s) 604 may be part ofthe one or more processor(s) 602. In various embodiments, computerdevice 600 may include printed circuit board (PCB) 606. For theseembodiments, the one or more processor(s) 602 and communication chip(s)604 may be disposed thereon. In alternate embodiments, the variouscomponents may be coupled without the employment of PCB 606.

Depending on its applications, computer device 600 may include othercomponents that may or may not be physically and electrically coupled tothe PCB 606. These other components include, but are not limited to,memory controller 608, volatile memory (e.g., dynamic random accessmemory (DRAM) 610), non-volatile memory such as read only memory (ROM)612, flash memory 614, storage device 616 (e.g., a hard-disk drive(HDD)), an I/O controller 618, a digital signal processor 620, a cryptoprocessor 622, a graphics processor 624 (e.g., a graphics processingunit (GPU) or other circuitry for performing graphics), one or moreantenna 626, a display which may be or work in conjunction with a touchscreen display 628, a touch screen controller 630, a battery 632, anaudio codec (not shown), a video codec (not shown), a positioning systemsuch as a global positioning system (GPS) device 634 (it will beappreciated other location technology may be used), a compass 636, anaccelerometer (not shown), a gyroscope (not shown), a speaker 638, acamera 640, and other mass storage devices (such as hard disk drive, asolid state drive, compact disk (CD), digital versatile disk (DVD)) (notshown), and so forth.

In some embodiments, the one or more processor(s) 602, flash memory 614,and/or storage device 616 may include associated firmware (not shown)storing programming instructions configured to enable computer device600, in response to execution of the programming instructions by one ormore processor(s) 602, to practice all or selected aspects of themethods described herein. In various embodiments, these aspects mayadditionally or alternatively be implemented using hardware separatefrom the one or more processor(s) 602, flash memory 614, or storagedevice 616. In one embodiment, memory, such as flash memory 614 or othermemory in the computer device, is or may include a memory device that isa block addressable memory device, such as those based on NAND or NORtechnologies. A memory device may also include future generationnonvolatile devices, such as a three dimensional crosspoint memorydevice, or other byte addressable write-in-place nonvolatile memorydevices. In one embodiment, the memory device may be or may includememory devices that use chalcogenide glass, multi-threshold level NANDflash memory, NOR flash memory, single or multi-level Phase ChangeMemory (PCM), a resistive memory, nanowire memory, ferroelectrictransistor random access memory (FeTRAM), anti-ferroelectric memory,magnetoresistive random access memory (MRAM) memory that incorporatesmemristor technology, resistive memory including the metal oxide base,the oxygen vacancy base and the conductive bridge Random Access Memory(CB-RAM), or spin transfer torque (STT)-MRAM, a spintronic magneticjunction memory based device, a magnetic tunneling junction (MTJ) baseddevice, a DW (Domain Wall) and SOT (Spin Orbit Transfer) based device, athyristor based memory device, or a combination of any of the above, orother memory. The memory device may refer to the die itself and/or to apackaged memory product.

In various embodiments, one or more components of the computer device600 may implement an embodiment of, for example, the FIG. 1 beacon 102,mobile machine 108 or proxy 116, etc. Thus for example processor 602could correspond to operation of the FIG. 1 proxy communicating withmemory 610 though memory controller 608. In some embodiments, I/Ocontroller 618 may interface with one or more external devices toreceive a data. Additionally, or alternatively, the external devices maybe used to receive a data signal transmitted between components of thecomputer device 600.

The communication chip(s) 604 may enable wired and/or wirelesscommunications for the transfer of data to and from the computer device600. The term “wireless” and its derivatives may be used to describecircuits, devices, systems, methods, techniques, communicationschannels, etc., that may communicate data through the use of modulatedelectromagnetic radiation through a non-solid medium. The term does notimply that the associated devices do not contain any wires, although insome embodiments they might not. The communication chip(s) may implementany of a number of wireless standards or protocols, including but notlimited to IEEE 802.20, Long Term Evolution (LTE), LTE Advanced (LTE-A),General Packet Radio Service (GPRS), Evolution Data Optimized (Ev-DO),Evolved High Speed Packet Access (HSPA+), Evolved High Speed DownlinkPacket Access (HSDPA+), Evolved High Speed Uplink Packet Access(HSUPA+), Global System for Mobile Communications (GSM), Enhanced Datarates for GSM Evolution (EDGE), Code Division Multiple Access (CDMA),Time Division Multiple Access (TDMA), Digital Enhanced CordlessTelecommunications (DECT), Worldwide Interoperability for MicrowaveAccess (WiMAX), Bluetooth, derivatives thereof, as well as any otherwireless protocols that are designated as 3G, 4G, 5G, and beyond. Thecomputer device may include a plurality of communication chips 604. Forinstance, a first communication chip(s) may be dedicated to shorterrange wireless communications such as Wi-Fi and Bluetooth, and a secondcommunication chip 604 may be dedicated to longer range wirelesscommunications such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, Ev-DO, andothers.

The communication chip(s) may implement any number of standards,protocols, and/or technologies datacenters typically use, such asnetworking technology providing high-speed low latency communication.For example, the communication chip(s) may support RoCE (Remote DirectMemory Access (RDMA) over Converged Ethernet), e.g., version 1 or 2,which is a routable protocol having efficient data transfers across anetwork, and is discussed for example at Internet URLRDMAconsortium.com. The chip(s) may support Fibre Channel over Ethernet(FCoE), iWARP, or other high-speed communication technology, see forexample the OpenFabrics Enterprise Distribution (OFED™) documentationavailable at Internet URL OpenFabrics.org. It will be appreciateddatacenter environments benefit from highly efficient networks, storageconnectivity and scalability, e.g., Storage Area Networks (SANS),parallel computing using RDMA, Internet Wide Area Remote Protocol(iWARP), InfiniBand Architecture (IBA), and other such technology.Computer device 600 may support any of the infrastructures, protocolsand technology identified here, and since new high-speed technology isalways being implemented, it will be appreciated by one skilled in theart that the computer device is expected to support equivalentscurrently known or technology implemented in future.

In various implementations, the computer device 600 may be a laptop, anetbook, a notebook, an ultrabook, a smartphone, a computer tablet, apersonal digital assistant (PDA), an ultra-mobile PC, a mobile phone, adesktop computer, a server, a printer, a scanner, a monitor, a set-topbox, an entertainment control unit (e.g., a gaming console or automotiveentertainment unit), a digital camera, an appliance, a portable musicplayer, or a digital video recorder, or a transportation device (e.g.,any motorized or manual device such as a bicycle, motorcycle,automobile, taxi, train, plane, etc.). In further implementations, thecomputer device 600 may be any other electronic device that processesdata.

FIG. 7 illustrates an exemplary computer-readable storage medium 700.The storage medium may be transitory, non-transitory or a combination oftransitory and non-transitory media, and the medium may be suitable foruse to store instructions that cause an apparatus, machine or otherdevice, in response to execution of the instructions by the apparatus,to practice selected aspects of the present disclosure. As will beappreciated by one skilled in the art, the present disclosure may beembodied as methods or computer program products. Accordingly, thepresent disclosure, in addition to being embodied in hardware as earlierdescribed, may take the form of an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to as a “circuit,” “module” or “system.”Furthermore, the present disclosure may take the form of a computerprogram product embodied in any tangible or non-transitory medium ofexpression having computer-usable program code embodied in the medium.As shown, non-transitory computer-readable storage medium 702 mayinclude a number of programming instructions 704. Programminginstructions 704 may be configured to enable a device, e.g., computerdevice 600, in response to execution of the programming instructions, toimplement (aspects of) technology disclosed herein. In alternateembodiments, programming instructions 704 may be disposed on multiplecomputer-readable non-transitory storage media 702 instead. In stillother embodiments, programming instructions 704 may be disposed oncomputer-readable transitory storage media 702, such as, signals.

Any combination of one or more computer usable or computer readablemedium(s) may be utilized. The computer-usable or computer-readablemedium may be, for example but not limited to, an electronic, magnetic,optical, electromagnetic, infrared, or semiconductor system, apparatus,device, or propagation medium. More specific examples (a non-exhaustivelist) of the computer-readable medium would include the following: anelectrical connection having one or more wires, a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CD-ROM), an optical storage device, a transmission media such as thosesupporting the Internet or an intranet, or a magnetic storage device.Note that the computer-usable or computer-readable medium could even bepaper or another suitable medium upon which the program is printed, asthe program can be electronically captured, via, for instance, opticalscanning of the paper or other medium, then compiled, interpreted, orotherwise processed in a suitable manner, if necessary, and then storedin a computer memory. In the context of this document, a computer-usableor computer-readable medium may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer-usable medium may include a propagated data signal with thecomputer-usable program code embodied therewith, either in baseband oras part of a carrier wave. The computer usable program code may betransmitted using any appropriate medium, including but not limited towireless, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the presentdisclosure may be written in any combination of one or more programminglanguages, including an object oriented programming language such asJava, Smalltalk, C++ or the like and conventional procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The program code may execute entirely on the user's computer,partly on the user's computer, as a stand-alone software package, partlyon the user's computer and partly on a remote computer or entirely onthe remote computer or server. In the latter scenario, the remotecomputer may be connected to the user's computer through any type ofnetwork, including a local area network (LAN) or a wide area network(WAN), or the connection may be made to an external computer (forexample, through the Internet using an Internet Service Provider).Cooperative program execution may be for a fee based on a commercialtransaction, such as a negotiated rate (offer/accept) arrangement,established and/or customary rates, and may include micropaymentsbetween device(s) cooperatively executing the program or storing and/ormanaging associated data.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks. The computer program instructions may also beloaded onto a computer or other programmable data processing apparatusto cause a series of operational steps to be performed on the computeror other programmable apparatus to produce a computer implementedprocess such that the instructions which are executed provide processesfor implementing the functions/acts specified in the flowchart and/orblock diagram block or blocks.

FIG. 8 illustrates an example domain topology 800 for respectiveinternet-of-things (IoT) networks coupled through links to respectivegateways. The Internet of Things (IoT) is a concept in which a largenumber of computing devices are interconnected to each other and to theInternet to provide functionality and data acquisition at very lowlevels. Thus, as used herein, an IoT device may include a semiautonomousdevice performing a function, such as sensing or control, among others,in communication with other IoT devices and a wider network, such as theInternet.

Often, IoT devices are limited in memory, size, or functionality,allowing larger numbers to be deployed for a similar cost to smallernumbers of larger devices. However, an IoT device may be a smart phone,laptop, tablet, or PC, or other larger device. Further, an IoT devicemay be a virtual device, such as an application on a smart phone orother computing device. IoT devices may include IoT gateways, used tocouple IoT devices to other IoT devices and to cloud applications, fordata storage, process control, and the like.

Networks of IoT devices may include commercial and home automationdevices, such as water distribution systems, electric power distributionsystems, pipeline control systems, plant control systems, lightswitches, thermostats, locks, cameras, alarms, motion sensors, and thelike. The IoT devices may be accessible through remote computers,servers, and other systems, for example, to control systems or accessdata.

The future growth of the Internet and like networks may involve verylarge numbers of IoT devices. Accordingly, in the context of thetechniques discussed herein, a number of innovations for such futurenetworking will address the need for all these layers to growunhindered, to discover and make accessible connected resources, and tosupport the ability to hide and compartmentalize connected resources.Any number of network protocols and communications standards may beused, wherein each protocol and standard is designed to address specificobjectives. Further, the protocols are part of the fabric supportinghuman accessible services that operate regardless of location, time orspace. The innovations include service delivery and associatedinfrastructure, such as hardware and software; security enhancements;and the provision of services based on Quality of Service (QoS) termsspecified in service level and service delivery agreements. As will beunderstood, the use of IoT devices and networks, such as thoseintroduced in FIGS. 8 and 9, present a number of new challenges in aheterogeneous network of connectivity comprising a combination of wiredand wireless technologies.

FIG. 8 specifically provides a simplified drawing of a domain topologythat may be used for a number of internet-of-things (IoT) networkscomprising IoT devices 804, with the IoT networks 856, 858, 860, 862,coupled through backbone links 802 to respective gateways 854. Forexample, a number of IoT devices 804 may communicate with a gateway 854,and with each other through the gateway 854. To simplify the drawing,not every IoT device 804, or communications link (e.g., link 816, 822,828, or 832) is labeled. The backbone links 802 may include any numberof wired or wireless technologies, including optical networks, and maybe part of a local area network (LAN), a wide area network (WAN), or theInternet. Additionally, such communication links facilitate opticalsignal paths among both IoT devices 804 and gateways 854, including theuse of MUXing/deMUXing components that facilitate interconnection of thevarious devices.

The network topology may include any number of types of IoT networks,such as a mesh network provided with the network 856 using Bluetooth lowenergy (BLE) links 822. Other types of IoT networks that may be presentinclude a wireless local area network (WLAN) network 858 used tocommunicate with IoT devices 804 through IEEE 802.8 (Wi-Fi®) links 828,a cellular network 860 used to communicate with IoT devices 804 throughan LTE/LTE-A (4G) or 5G cellular network, and a low-power wide area(LPWA) network 862, for example, a LPWA network compatible with theLoRaWan specification promulgated by the LoRa alliance, or a IPv6 overLow Power Wide-Area Networks (LPWAN) network compatible with aspecification promulgated by the Internet Engineering Task Force (IETF).Further, the respective IoT networks may communicate with an outsidenetwork provider (e.g., a tier 2 or tier 3 provider) using any number ofcommunications links, such as an LTE cellular link, an LPWA link, or alink based on the IEEE 802.15.4 standard, such as Zigbee®. Therespective IoT networks may also operate with use of a variety ofnetwork and internet application protocols such as ConstrainedApplication Protocol (CoAP). The respective IoT networks may also beintegrated with coordinator devices that provide a chain of links thatforms cluster tree of linked devices and networks.

Each of these IoT networks may provide opportunities for new technicalfeatures, such as those as described herein. The improved technologiesand networks may enable the exponential growth of devices and networks,including the use of IoT networks into as fog devices or systems. As theuse of such improved technologies grows, the IoT networks may bedeveloped for self-management, functional evolution, and collaboration,without needing direct human intervention. The improved technologies mayeven enable IoT networks to function without centralized controlledsystems. Accordingly, the improved technologies described herein may beused to automate and enhance network management and operation functionsfar beyond current implementations.

In an example, communications between IoT devices 804, such as over thebackbone links 802, may be protected by a decentralized system forauthentication, authorization, and accounting (AAA). In a decentralizedAAA system, distributed payment, credit, audit, authorization, andauthentication systems may be implemented across interconnectedheterogeneous network infrastructure. This allows systems and networksto move towards autonomous operations. In these types of autonomousoperations, machines may even contract for human resources and negotiatepartnerships with other machine networks. This may allow the achievementof mutual objectives and balanced service delivery against outlined,planned service level agreements as well as achieve solutions thatprovide metering, measurements, traceability and trackability. Thecreation of new supply chain structures and methods may enable amultitude of services to be created, mined for value, and collapsedwithout any human involvement.

Such IoT networks may be further enhanced by the integration of sensingtechnologies, such as sound, light, electronic traffic, facial andpattern recognition, smell, vibration, into the autonomous organizationsamong the IoT devices. The integration of sensory systems may allowsystematic and autonomous communication and coordination of servicedelivery against contractual service objectives, orchestration andquality of service (QoS) based swarming and fusion of resources. Some ofthe individual examples of network-based resource processing include thefollowing.

The mesh network 856, for instance, may be enhanced by systems thatperform inline data-to-information transforms. For example, self-formingchains of processing resources comprising a multi-link network maydistribute the transformation of raw data to information in an efficientmanner, and the ability to differentiate between assets and resourcesand the associated management of each. Furthermore, the propercomponents of infrastructure and resource based trust and serviceindices may be inserted to improve the data integrity, quality,assurance and deliver a metric of data confidence.

The WLAN network 858, for instance, may use systems that performstandards conversion to provide multi-standard connectivity, enablingIoT devices 804 using different protocols to communicate. Furthersystems may provide seamless interconnectivity across a multi-standardinfrastructure comprising visible Internet resources and hidden Internetresources.

Communications in the cellular network 860, for instance, may beenhanced by systems that offload data, extend communications to moreremote devices, or both. The LPWA network 862 may include systems thatperform non-Internet protocol (IP) to IP interconnections, addressing,and routing. Further, each of the IoT devices 804 may include theappropriate transceiver for wide area communications with that device.Further, each IoT device 804 may include other transceivers forcommunications using additional protocols and frequencies. This isdiscussed further with respect to the communication environment andhardware of an IoT processing device depicted in other illustratedembodiments.

Finally, clusters of IoT devices may be equipped to communicate withother IoT devices as well as with a cloud network. This may allow theIoT devices to form an ad-hoc network between the devices, allowing themto function as a single device, which may be termed a fog device. Thisconfiguration is discussed further with respect to FIG. 9 below.

FIG. 9 illustrates a cloud computing network in communication with amesh network of IoT devices (devices 902) operating as a fog device atthe edge of the cloud computing network. The mesh network of IoT devicesmay be termed a fog 920, operating at the edge of the cloud 900. Tosimplify the diagram, not every IoT device 902 is labeled.

The fog 920 may be considered to be a massively interconnected networkwherein a number of IoT devices 902 are in communications with eachother, for example, by radio links 922. As an example, thisinterconnected network may be facilitated using an interconnectspecification released by the Open Connectivity Foundation™ (OCF). Thisstandard allows devices to discover each other and establishcommunications for interconnects. Other interconnection protocols mayalso be used, including, for example, the optimized link state routing(OLSR) Protocol, the better approach to mobile ad-hoc networking(B.A.T.M.A.N.) routing protocol, or the OMA Lightweight M2M (LWM2M)protocol, among others.

Three types of IoT devices 902 are shown in this example, gateways 904,data aggregators 926, and sensors 928, although any combinations of IoTdevices 902 and functionality may be used. The gateways 904 may be edgedevices that provide communications between the cloud 900 and the fog920, and may also provide the backend process function for data obtainedfrom sensors 928, such as motion data, flow data, temperature data, andthe like. The data aggregators 926 may collect data from any number ofthe sensors 928, and perform the back end processing function for theanalysis. The results, raw data, or both may be passed along to thecloud 900 through the gateways 904. The sensors 928 may be full IoTdevices 902, for example, capable of both collecting data and processingthe data. In some cases, the sensors 928 may be more limited infunctionality, for example, collecting the data and allowing the dataaggregators 926 or gateways 904 to process the data.

Communications from any IoT device 902 may be passed along a convenientpath (e.g., a most convenient path) between any of the IoT devices 902to reach the gateways 904. In these networks, the number ofinterconnections provide substantial redundancy, allowing communicationsto be maintained, even with the loss of a number of IoT devices 902.Further, the use of a mesh network may allow IoT devices 902 that arevery low power or located at a distance from infrastructure to be used,as the range to connect to another IoT device 902 may be much less thanthe range to connect to the gateways 904.

The fog 920 provided from these IoT devices 902 may be presented todevices in the cloud 900, such as a server 906, as a single devicelocated at the edge of the cloud 900, e.g., a fog device. In thisexample, the alerts coming from the fog device may be sent without beingidentified as coming from a specific IoT device 902 within the fog 920.In this fashion, the fog 920 may be considered a distributed platformthat provides computing and storage resources to perform processing ordata-intensive tasks such as data analytics, data aggregation, andmachine-learning, among others.

In some examples, the IoT devices 902 may be configured using animperative programming style, e.g., with each IoT device 902 having aspecific function and communication partners. However, the IoT devices902 forming the fog device may be configured in a declarativeprogramming style, allowing the IoT devices 902 to reconfigure theiroperations and communications, such as to determine needed resources inresponse to conditions, queries, and device failures. As an example, aquery from a user located at a server 906 about the operations of asubset of equipment monitored by the IoT devices 902 may result in thefog 920 device selecting the IoT devices 902, such as particular sensors928, needed to answer the query. The data from these sensors 928 maythen be aggregated and analyzed by any combination of the sensors 928,data aggregators 926, or gateways 904, before being sent on by the fog920 device to the server 906 to answer the query. In this example, IoTdevices 902 in the fog 920 may select the sensors 928 used based on thequery, such as adding data from flow sensors or temperature sensors.Further, if some of the IoT devices 902 are not operational, other IoTdevices 902 in the fog 920 device may provide analogous data, ifavailable.

In other examples, the operations and functionality described above maybe embodied by a IoT device machine in the example form of an electronicprocessing system, within which a set or sequence of instructions may beexecuted to cause the electronic processing system to perform any one ofthe methodologies discussed herein, according to an example embodiment.The machine may be an IoT device or an IoT gateway, including a machineembodied by aspects of a personal computer (PC), a tablet PC, a personaldigital assistant (PDA), a mobile telephone or smartphone, or anymachine capable of executing instructions (sequential or otherwise) thatspecify actions to be taken by that machine. Further, while only asingle machine may be depicted and referenced in the example above, suchmachine shall also be taken to include any collection of machines thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.Further, these and like examples to a processor-based system shall betaken to include any set of one or more machines that are controlled byor operated by a processor (e.g., a computer) to individually or jointlyexecute instructions to perform any one or more of the methodologiesdiscussed herein.

FIG. 10 illustrates a drawing of a cloud computing network, or cloud1000, in communication with a number of Internet of Things (IoT)devices. The cloud 1000 may represent the Internet, or may be a localarea network (LAN), or a wide area network (WAN), such as a proprietarynetwork for a company. The IoT devices may include any number ofdifferent types of devices, grouped in various combinations. Forexample, a traffic control group 1006 may include IoT devices alongstreets in a city. These IoT devices may include stoplights, trafficflow monitors, cameras, weather sensors, and the like. The trafficcontrol group 1006, or other subgroups, may be in communication with thecloud 1000 through wired or wireless links 1008, such as LPWA links,optical links, and the like. Further, a wired or wireless sub-network1012 may allow the IoT devices to communicate with each other, such asthrough a local area network, a wireless local area network, and thelike. The IoT devices may use another device, such as a gateway 1010 or1028 to communicate with remote locations such as the cloud 1000; theIoT devices may also use one or more servers 1030 to facilitatecommunication with the cloud 1000 or with the gateway 1010. For example,the one or more servers 1030 may operate as an intermediate network nodeto support a local edge cloud or fog implementation among a local areanetwork. Further, the gateway 1028 that is depicted may operate in acloud-to-gateway-to-many edge devices configuration, such as with thevarious IoT devices 1014, 1020, 1024 being constrained or dynamic to anassignment and use of resources in the cloud 1000.

Other example groups of IoT devices may include remote weather stations1014, local information terminals 1016, alarm systems 1018, automatedteller machines 1020, alarm panels 1022, or moving vehicles, such asemergency vehicles 1024 or other vehicles 1026, among many others. Eachof these IoT devices may be in communication with other IoT devices,with servers 1004, with another IoT fog device or system (not shown, butdepicted in FIG. 9), or a combination therein. The groups of IoT devicesmay be deployed in various residential, commercial, and industrialsettings (including in both private or public environments).

As can be seen from FIG. 10, a large number of IoT devices may becommunicating through the cloud 1000. This may allow different IoTdevices to request or provide information to other devices autonomously.For example, a group of IoT devices (e.g., the traffic control group1006) may request a current weather forecast from a group of remoteweather stations 1014, which may provide the forecast without humanintervention. Further, an emergency vehicle 1024 may be alerted by anautomated teller machine 1020 that a burglary is in progress. As theemergency vehicle 1024 proceeds towards the automated teller machine1020, it may access the traffic control group 1006 to request clearanceto the location, for example, by lights turning red to block crosstraffic at an intersection in sufficient time for the emergency vehicle1024 to have unimpeded access to the intersection.

Clusters of IoT devices, such as the remote weather stations 1014 or thetraffic control group 1006, may be equipped to communicate with otherIoT devices as well as with the cloud 1000. This may allow the IoTdevices to form an ad-hoc network between the devices, allowing them tofunction as a single device, which may be termed a fog device or system(e.g., as described above with reference to FIG. 9).

FIG. 11 is a block diagram of an example of components that may bepresent in an IoT device 1150 for implementing the techniques describedherein. The IoT device 1150 may include any combinations of thecomponents shown in the example or referenced in the disclosure above.The components may be implemented as ICs, portions thereof, discreteelectronic devices, or other modules, logic, hardware, software,firmware, or a combination thereof adapted in the IoT device 1150, or ascomponents otherwise incorporated within a chassis of a larger system.Additionally, the block diagram of FIG. 11 is intended to depict ahigh-level view of components of the IoT device 1150. However, some ofthe components shown may be omitted, additional components may bepresent, and different arrangement of the components shown may occur inother implementations.

The IoT device 1150 may include a processor 1152, which may be amicroprocessor, a multi-core processor, a multithreaded processor, anultra-low voltage processor, an embedded processor, or other knownprocessing element. The processor 1152 may be a part of a system on achip (SoC) in which the processor 1152 and other components are formedinto a single integrated circuit, or a single package, such as theEdison™ or Galileo™ SoC boards from Intel. As an example, the processor1152 may include an Intel® Architecture Core™ based processor, such as aQuark™, an Atom™, an i3, an i5, an i7, or an MCU-class processor, oranother such processor available from Intel® Corporation, Santa Clara,Calif. However, any number other processors may be used, such asavailable from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, Calif.,a MIPS-based design from MIPS Technologies, Inc. of Sunnyvale, Calif.,an ARM-based design licensed from ARM Holdings, Ltd. or customerthereof, or their licensees or adopters. The processors may includeunits such as an A5-A10 processor from Apple® Inc., a Snapdragon™processor from Qualcomm® Technologies, Inc., or an OMAP™ processor fromTexas Instruments, Inc.

The processor 1152 may communicate with a system memory 1154 over aninterconnect 1156 (e.g., a bus). Any number of memory devices may beused to provide for a given amount of system memory. As examples, thememory may be random access memory (RAM) in accordance with a JointElectron Devices Engineering Council (JEDEC) design such as the DDR ormobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4 ). Invarious implementations the individual memory devices may be of anynumber of different package types such as single die package (SDP), dualdie package (DDP) or quad die package (Q17P). These devices, in someexamples, may be directly soldered onto a motherboard to provide a lowerprofile solution, while in other examples the devices are configured asone or more memory modules that in turn couple to the motherboard by agiven connector. Any number of other memory implementations may be used,such as other types of memory modules, e.g., dual inline memory modules(DIMMs) of different varieties including but not limited to microDIMMsor MiniDIMMs.

To provide for persistent storage of information such as data,applications, operating systems and so forth, a storage 1158 may alsocouple to the processor 1152 via the interconnect 1156. In an examplethe storage 1158 may be implemented via a solid state disk drive (SSDD).Other devices that may be used for the storage 1158 include flash memorycards, such as SD cards, microSD cards, xD picture cards, and the like,and USB flash drives. In low power implementations, the storage 1158 maybe on-die memory or registers associated with the processor 1152.However, in some examples, the storage 1158 may be implemented using amicro hard disk drive (HDD). Further, any number of new technologies maybe used for the storage 1158 in addition to, or instead of, thetechnologies described, such resistance change memories, phase changememories, holographic memories, or chemical memories, among others.

The components may communicate over the interconnect 1156. Theinterconnect 1156 may include any number of technologies, includingindustry standard architecture (ISA), extended ISA (EISA), peripheralcomponent interconnect (PCI), peripheral component interconnect extended(PCIx), PCI express (PCIe), or any number of other technologies. Theinterconnect 1156 may be a proprietary bus, for example, used in a SoCbased system. Other bus systems may be included, such as an I2Cinterface, an SPI interface, point to point interfaces, and a power bus,among others.

The interconnect 1156 may couple the processor 1152 to a meshtransceiver 1162, for communications with other mesh devices 1164. Themesh transceiver 1162 may use any number of frequencies and protocols,such as 2.4 Gigahertz (GHz) transmissions under the IEEE 802.15.4standard, using the Bluetooth® low energy (BLE) standard, as defined bythe Bluetooth® Special Interest Group, or the ZigBee® standard, amongothers. Any number of radios, configured for a particular wirelesscommunication protocol, may be used for the connections to the meshdevices 1164. For example, a WLAN unit may be used to implement Wi-Fi™communications in accordance with the Institute of Electrical andElectronics Engineers (IEEE) 802.11 standard. In addition, wireless widearea communications, e.g., according to a cellular or other wirelesswide area protocol, may occur via a WWAN unit.

The mesh transceiver 1162 may communicate using multiple standards orradios for communications at different range. For example, the IoTdevice 1150 may communicate with close devices, e.g., within about 10meters, using a local transceiver based on BLE, or another low powerradio, to save power. More distant mesh devices 1164, e.g., within about50 meters, may be reached over ZigBee or other intermediate powerradios. Both communications techniques may take place over a singleradio at different power levels, or may take place over separatetransceivers, for example, a local transceiver using BLE and a separatemesh transceiver using ZigBee.

A wireless network transceiver 1166 may be included to communicate withdevices or services in the cloud 1100 via local or wide area networkprotocols. The wireless network transceiver 1166 may be a LPWAtransceiver that follows the IEEE 802.15.4, or IEEE 802.15.4g standards,among others. The IoT device 1150 may communicate over a wide area usingLoRaWAN™ (Long Range Wide Area Network) developed by Semtech and theLoRa Alliance. The techniques described herein are not limited to thesetechnologies, but may be used with any number of other cloudtransceivers that implement long range, low bandwidth communications,such as Sigfox, and other technologies. Further, other communicationstechniques, such as time-slotted channel hopping, described in the IEEE802.15.4e specification may be used.

Any number of other radio communications and protocols may be used inaddition to the systems mentioned for the mesh transceiver 1162 andwireless network transceiver 1166, as described herein. For example, theradio transceivers 1162 and 1166 may include an LTE or other cellulartransceiver that uses spread spectrum (SPA/SAS) communications forimplementing high speed communications. Further, any number of otherprotocols may be used, such as Wi-Fi® networks for medium speedcommunications and provision of network communications.

The radio transceivers 1162 and 1166 may include radios that arecompatible with any number of 3GPP (Third Generation PartnershipProject) specifications, notably Long Term Evolution (LTE), Long TermEvolution-Advanced (LTE-A), and Long Term Evolution-Advanced Pro (LTE-APro). It can be noted that radios compatible with any number of otherfixed, mobile, or satellite communication technologies and standards maybe selected. These may include, for example, any Cellular Wide Arearadio communication technology, which may include e.g. a 5th Generation(5G) communication systems, a Global System for Mobile Communications(GSM) radio communication technology, a General Packet Radio Service(GPRS) radio communication technology, or an Enhanced Data Rates for GSMEvolution (EDGE) radio communication technology, a UMTS (UniversalMobile Telecommunications System) communication technology, In additionto the standards listed above, any number of satellite uplinktechnologies may be used for the wireless network transceiver 1166,including, for example, radios compliant with standards issued by theITU (International Telecommunication Union), or the ETSI (EuropeanTelecommunications Standards Institute), among others. The examplesprovided herein are thus understood as being applicable to various othercommunication technologies, both existing and not yet formulated.

A network interface controller (NIC) 1168 may be included to provide awired communication to the cloud 1100 or to other devices, such as themesh devices 1164. The wired communication may provide an Ethernetconnection, or may be based on other types of networks, such asController Area Network (CAN), Local Interconnect Network (LIN),DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among manyothers. An additional NIC 1168 may be included to allow connect to asecond network, for example, a NIC 1168 providing communications to thecloud over Ethernet, and a second NIC 1168 providing communications toother devices over another type of network.

The interconnect 1156 may couple the processor 1152 to an externalinterface 1170 that is used to connect external devices or subsystems.The external devices may include sensors 1172, such as accelerometers,level sensors, flow sensors, optical light sensors, camera sensors,temperature sensors, a global positioning system (GPS) sensors, pressuresensors, barometric pressure sensors, and the like. The externalinterface 1170 further may be used to connect the IoT device 1150 toactuators 1174, such as power switches, valve actuators, an audiblesound generator, a visual warning device, and the like.

In some optional examples, various input/output (I/O) devices may bepresent within, or connected to, the IoT device 1150. For example, adisplay or other output device 1184 may be included to show information,such as sensor readings or actuator position. An input device 1186, suchas a touch screen or keypad may be included to accept input. An outputdevice 1184 may include any number of forms of audio or visual display,including simple visual outputs such as binary status indicators (e.g.,LEDs) and multi-character visual outputs, or more complex outputs suchas display screens (e.g., LCD screens), with the output of characters,graphics, multimedia objects, and the like being generated or producedfrom the operation of the IoT device 1150.

A battery 1176 may power the IoT device 1150, although in examples inwhich the IoT device 1150 is mounted in a fixed location, it may have apower supply coupled to an electrical grid. The battery 1176 may be alithium ion battery, or a metal-air battery, such as a zinc-air battery,an aluminum-air battery, a lithium-air battery, and the like.

A battery monitor/charger 1178 may be included in the IoT device 1150 totrack the state of charge (SoCh) of the battery 1176. The batterymonitor/charger 1178 may be used to monitor other parameters of thebattery 1176 to provide failure predictions, such as the state of health(SoH) and the state of function (SoF) of the battery 1176. The batterymonitor/charger 1178 may include a battery monitoring integratedcircuit, such as an LTC4020 or an LTC2990 from Linear Technologies, anADT7488A from ON Semiconductor of Phoenix, Ariz., or an IC from theUCD90xxx family from Texas Instruments of Dallas, Tex. The batterymonitor/charger 1178 may communicate the information on the battery 1176to the processor 1152 over the interconnect 1156. The batterymonitor/charger 1178 may also include an analog-to-digital (ADC)convertor that allows the processor 1152 to monitor directly the voltageof the battery 1176 or the current flow from the battery 1176. Thebattery parameters may be used to determine actions that the IoT device1150 may perform, such as transmission frequency, mesh networkoperation, sensing frequency, and the like.

A power block 1180, or other power supply coupled to a grid, may becoupled with the battery monitor/charger 1178 to charge the battery1176. In some examples, the power block 1180 may be replaced with awireless power receiver to obtain the power wirelessly, for example,through a loop antenna in the IoT device 1150. A wireless batterycharging circuit, such as an LTC4020 chip from Linear Technologies ofMilpitas, Calif., among others, may be included in the batterymonitor/charger 1178. The specific charging circuits chosen depend onthe size of the battery 1176, and thus, the current required. Thecharging may be performed using the Airfuel standard promulgated by theAirfuel Alliance, the Qi wireless charging standard promulgated by theWireless Power Consortium, or the Rezence charging standard, promulgatedby the Alliance for Wireless Power, among others.

The storage 1158 may include instructions 1182 in the form of software,firmware, or hardware commands to implement the techniques describedherein. Although such instructions 1182 are shown as code blocksincluded in the memory 1154 and the storage 1158, it may be understoodthat any of the code blocks may be replaced with hardwired circuits, forexample, built into an application specific integrated circuit (ASIC).

In an example, the instructions 1182 provided via the memory 1154, thestorage 1158, or the processor 1152 may be embodied as a non-transitory,machine readable medium 1160 including code to direct the processor 1152to perform electronic operations in the IoT device 1150. The processor1152 may access the non-transitory, machine readable medium 1160 overthe interconnect 1156. For instance, the non-transitory, machinereadable medium 1160 may be embodied by devices described for thestorage 1158 of FIG. 11 or may include specific storage units such asoptical disks, flash drives, or any number of other hardware devices.The non-transitory, machine readable medium 1160 may includeinstructions to direct the processor 1152 to perform a specific sequenceor flow of actions, for example, as described with respect to theflowchart(s) and block diagram(s) of operations and functionalitydepicted above.

In further examples, a machine-readable medium also includes anytangible medium that is capable of storing, encoding or carryinginstructions for execution by a machine and that cause the machine toperform any one or more of the methodologies of the present disclosureor that is capable of storing, encoding or carrying data structuresutilized by or associated with such instructions. A “machine-readablemedium” thus may include, but is not limited to, solid-state memories,and optical and magnetic media. Specific examples of machine-readablemedia include non-volatile memory, including but not limited to, by wayof example, semiconductor memory devices (e.g., electricallyprogrammable read-only memory (EPROM), electrically erasableprogrammable read-only memory (EEPROM)) and flash memory devices;magnetic disks such as internal hard disks and removable disks;magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructionsembodied by a machine-readable medium may further be transmitted orreceived over a communications network using a transmission medium via anetwork interface device utilizing any one of a number of transferprotocols (e.g., HTTP).

It should be understood that the functional units or capabilitiesdescribed in this specification may have been referred to or labeled ascomponents or modules, in order to more particularly emphasize theirimplementation independence. Such components may be embodied by anynumber of software or hardware forms. For example, a component or modulemay be implemented as a hardware circuit comprising customvery-large-scale integration (VLSI) circuits or gate arrays,off-the-shelf semiconductors such as logic chips, transistors, or otherdiscrete components. A component or module may also be implemented inprogrammable hardware devices such as field programmable gate arrays,programmable array logic, programmable logic devices, or the like.Components or modules may also be implemented in software for executionby various types of processors. An identified component or module ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions, which may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified component or module need not be physicallylocated together, but may comprise disparate instructions stored indifferent locations which, when joined logically together, comprise thecomponent or module and achieve the stated purpose for the component ormodule.

Indeed, a component or module of executable code may be a singleinstruction, or many instructions, and may even be distributed overseveral different code segments, among different programs, and acrossseveral memory devices or processing systems. In particular, someaspects of the described process (such as code rewriting and codeanalysis) may take place on a different processing system (e.g., in acomputer in a data center), than that in which the code is deployed(e.g., in a computer embedded in a sensor or robot). Similarly,operational data may be identified and illustrated herein withincomponents or modules, and may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set, or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork. The components or modules may be passive or active, includingagents operable to perform desired functions. Additional examples of thepresently described method, system, and device embodiments include thefollowing, non-limiting configurations. Each of the followingnon-limiting examples may stand on its own, or may be combined in anypermutation or combination with any one or more of the other examplesprovided below or throughout the present disclosure.

Example 1 may be a proxy for at least the physical-web, the proxy tocommunicate over a first communication path with a mobile machine, themobile machine at least temporarily to communicate with a beaconbroadcasting beacon data to the mobile machine over a secondcommunication path, the proxy comprising: the first communication pathto receive mobile data from the mobile machine; a security module to atleast validate the mobile data corresponds to the beacon data; a contextanalyzer to validate the mobile data complies with a context for thebeacon; a redirector to send a redirection to the mobile machine basedat least in part on the mobile data; and a data store to store an atleast one target for the redirector, wherein the data store maydynamically change the redirection to a selected one of the at least onetarget based at least in part on the context for the beacon.

Example 2 may be the proxy of example 1, in which the beacon has anassociated security feature, wherein the security module validates themobile data based at least in part on the security feature.

Example 3 may be the proxy of example 2, wherein: the security featureincludes an encoding operation of at least a portion of the beacon datain accord with a cryptosystem; and the security module validates themobile data by at least applying a verification operation of thecryptosystem that corresponds to the encoding operation.

Example 4 may be example 3, wherein the encoding operation is a selectedone of: a public key cryptosystem (PKI) signing of the at least aportion of the beacon data; or a PKI encryption of the at least aportion of the beacon data.

Example 5 may be example 1, in which the beacon data includes a firstuniform resource locator (URL) broadcast by the beacon, the proxyfurther comprising: a search module to determine if a second URL is inthe mobile data; a comparison module to determine if the second URLcorresponds to the first URL; a database storing at least one known URLassociated with at least the beacon; wherein the context for the beaconincludes the second URL being in the database storing the at least oneknown URL.

Example 6 may be example 1, wherein the context analyzer validates thebeacon data against an expectation of contact from devices receiving thebeacon data.

Example 7 may be example 6, wherein the expectation includes receivingthe mobile data during an in-service time associated with the beacon.

Example 8 may be example 1, wherein the redirector selects theredirection from the data store based at least in part on an eventselected from potential events associated with the beacon, the potentialevents including at least a holiday, or an entertainment event proximateto the beacon.

Example 8 may be a physical-web beacon to communicate over a firstnetwork with a mobile machine, to communicate over a second network witha management device, the mobile machine to communicate with a proxy toredirect the mobile machine to a network resource on a second networkbased at least in part on data provided over the first network, thebeacon comprising: a first communication interface path to broadcast abeacon data to the mobile machine over the first network; a secondcommunication interface to receive an update from the management deviceover the second network, the update encoded in accord with acryptosystem; a context analyzer to at least determine a context for thebeacon; and a security module to at least validate the update from themanagement device based on the context.

Example 10 may be example 9, wherein the validate the update is alsobased at least in part on the cryptosystem.

Example 11 may be example 9, wherein the cryptosystem includes anencoding operation that is a selected one of: a public key cryptosystem(PKI) signing of the at least a portion of the beacon data; or a PKIencryption of the at least a portion of the beacon data.

Example 12 may be example 9, wherein the beacon data includes a firstuniform resource locator (URL); and the beacon data is arranged so as tobe parseable by the proxy to facilitate the proxy to identify the firstURL and based thereon to perform the redirect of the mobile machine to asecond URL.

Example 13 may be example 9, wherein the context analyzer may monitorcontact with the beacon against an expectation of contact from devices,and may log an exception if the expectation is not met.

Example 11 may be example 13, wherein the expectation includes whethercontact is received during an in-service time associated with thebeacon.

Example 15 may be a method for a proxy to communicate over a firstnetwork with a mobile machine, the mobile machine at least temporarilyto communicate with a beacon for the physical-web broadcasting beacondata to the mobile machine, the method comprising: receiving the mobiledata from the mobile machine; validating the mobile data corresponds tothe beacon data; validating the mobile data complies with a context forthe beacon; dynamically selecting a redirection target from a data storebased at least in part on the mobile data and based at least in part onthe context for the beacon; and redirecting the mobile machine based tothe redirection target.

Example 16 may be example 15, in which the beacon has an associatedsecurity feature, the validating the mobile data further comprising:performing the validating the mobile data based at least in part on thesecurity feature.

Example 17 may be example 16, wherein: the security feature includes anencoding operation of at least a portion of the beacon data in accordwith a cryptosystem; and the security module validates the mobile databy at least applying a verification operation of the cryptosystem thatcorresponds to the encoding operation.

Example 18 may be example 17, wherein the encoding operation is aselected one of: a public key cryptosystem (PKI) signing of the at leasta portion of the beacon data; or a PKI encryption of the at least aportion of the beacon data.

Example 19 may be example 15, in which the beacon data includes a firstuniform resource locator (URL) broadcast by the beacon, furthercomprising: searching for a second URL in the mobile data; determiningif the second URL corresponds to the first URL; and validating themobile data satisfies an expectation of contact from the mobile device,wherein the expectation includes receiving the mobile data during anin-service time associated with the beacon.

Example 20 may be example 19, further comprising: setting theredirection target to URL determined based on the second URL.

Example 21 may be one or more non-transitory computer-readable mediahaving instructions for a proxy to communicate over a first network witha mobile machine, the mobile machine at least temporarily to communicatewith a beacon for the physical-web broadcasting beacon data to themobile machine, the instructions to provide for: receiving the mobiledata from the mobile machine; validating the mobile data corresponds tothe beacon data; validating the mobile data complies with a context forthe beacon; dynamically selecting a redirection target from a data storebased at least in part on the mobile data and based at least in part onthe context for the beacon; and redirecting the mobile machine based tothe redirection target.

Example 22 may be example 21 further including instructions to providefor: performing the validating the mobile data based at least in part onthe security feature.

Example 23 may be example 22, wherein the instructions for: the securityfeature includes further instructions to provide for an encodingoperation of at least a portion of the beacon data in accord with acryptosystem; and the security module includes further instructions toprovide for validating the mobile data by at least applying instructionsfor a verification operation of the cryptosystem that corresponds to theencoding operation.

Example 24 may be example 23, wherein the instructions to provide forthe encoding operation includes instructions to provide for a selectedone of: a public key cryptosystem (PKI) signing of the at least aportion of the beacon data; or a PKI encryption of the at least aportion of the beacon data.

Example 25 may be example 21, in which the beacon data includes a firstuniform resource locator (URL) broadcast by the beacon, the instructionsfor the proxy further including instructions to provide for: searchingfor a second URL in the mobile data; determining if the second URLcorresponds to the first URL; validating the mobile data satisfies anexpectation of contact from the mobile device, wherein the expectationincludes receiving the mobile data during an in-service time associatedwith the beacon; and setting the redirection target to URL determinedbased on the second URL.

Example 26 may be example any of examples 1-2, in which the beacon hasan associated security feature, wherein the security feature includes anencoding operation of at least a portion of the beacon data in accordwith a cryptosystem; and the security module validates the mobile databy at least applying a verification operation of the cryptosystem thatcorresponds to the encoding operation.

Example 27 may be example any of examples 1-4, in which the beacon dataincludes a first uniform resource locator (URL) broadcast by the beacon,the proxy further comprising: a search module to determine if a secondURL is in the mobile data; a comparison module to determine if thesecond URL corresponds to the first URL; a database storing at least oneknown URL associated with at least the beacon; wherein the context forthe beacon includes the second URL being in the database storing the atleast one known URL.

Example 28 may be example any of examples 1-5, wherein the contextanalyzer validates the beacon data against an expectation of contactfrom devices receiving the beacon data.

Example 29 may be example any of examples 1-7, wherein the redirectorselects the redirection from the data store based at least in part on anevent selected from potential events associated with the beacon, thepotential events including at least a holiday, or an entertainment eventproximate to the beacon.

Example 30 may be example any of examples 9-10, wherein the cryptosystemincludes an encoding operation that is a selected one of: a public keycryptosystem (PKI) signing of the at least a portion of the beacon data;or a PKI encryption of the at least a portion of the beacon data.

Example 31 may be example any of examples 9-11, wherein the beacon dataincludes a first uniform resource locator (URL); and the beacon data isarranged so as to be parseable by the proxy to facilitate the proxy toidentify the first URL and based thereon to perform the redirect of themobile machine to a second URL.

Example 32 may be example any of examples 9-12, wherein the contextanalyzer may monitor contact with the beacon against an expectation ofcontact from devices, and may log an exception if the expectation is notmet.

Example 33 may be example any of examples 15-16, in which the beacon hasan associated security feature, wherein: the security feature includesan encoding operation of at least a portion of the beacon data in accordwith a cryptosystem; and the security module validates the mobile databy at least applying a verification operation of the cryptosystem thatcorresponds to the encoding operation.

Example 34 may be example any of examples 15-18, in which the beacondata includes a first uniform resource locator (URL) broadcast by thebeacon, further comprising: searching for a second URL in the mobiledata; determining if the second URL corresponds to the first URL;validating the mobile data satisfies an expectation of contact from themobile device, wherein the expectation includes receiving the mobiledata during an in-service time associated with the beacon; and settingthe redirection target to URL determined based on the second URL.

Example 35 may be example any of examples 21-24, in which the beacondata includes a first uniform resource locator (URL) broadcast by thebeacon, the instructions for the proxy further including instructions toprovide for: searching for a second URL in the mobile data; determiningif the second URL corresponds to the first URL; validating the mobiledata satisfies an expectation of contact from the mobile device, whereinthe expectation includes receiving the mobile data during an in-servicetime associated with the beacon; and setting the redirection target toURL determined based on the second URL.

Example 36 may be a method for a proxy to communicate over a firstnetwork with a mobile machine, the mobile machine at least temporarilyto communicate with a beacon for the physical-web broadcasting beacondata to the mobile machine, the method comprising: means for receivingthe mobile data from the mobile machine; means for validating the mobiledata corresponds to the beacon data; means for validating the mobiledata complies with a context for the beacon; means for dynamicallyselecting a redirection target from a data store based at least in parton the mobile data and based at least in part on the context for thebeacon; and means for redirecting the mobile machine based to theredirection target.

Example 37 may be example 36, in which the beacon has an associatedsecurity feature, the validating the mobile data further comprising:means for performing the validating the mobile data based at least inpart on the security feature.

Example 38 may be example 37, wherein: the security feature includesmeans for an encoding operation of at least a portion of the beacon datain accord with a cryptosystem; and the security module validates themobile data by at least applying means for a verification operation ofthe cryptosystem that corresponds to the encoding operation.

Example 39 may be example 38, wherein the means for encoding operationis a selected one of: means for a public key cryptosystem (PKI) signingof the at least a portion of the beacon data; or means for a PKIencryption of the at least a portion of the beacon data.

Example 40 may be any of examples 36-39, in which the beacon dataincludes means for a first uniform resource locator (URL) broadcast bythe beacon, further comprising: means for searching for a second URL inthe mobile data; means for determining if the second URL corresponds tothe first URL; means for validating the mobile data satisfies anexpectation of contact from the mobile device, wherein the expectationincludes receiving the mobile data during an in-service time associatedwith the beacon; and means for setting the redirection target to URLdetermined based on the second URL.

Example 41 may be a proxy for at least the physical-web, the proxy tocommunicate over means for a first communication path with a mobilemachine, the mobile machine at least temporarily to communicate with abeacon broadcasting beacon data to the mobile machine over means for asecond communication path, the proxy comprising: the first communicationpath to receive mobile data from the mobile machine; means for asecurity module to at least validate the mobile data corresponds to thebeacon data; means for a context analyzer to validate the mobile datacomplies with a context for the beacon; means for a redirector to send aredirection to the mobile machine based at least in part on the mobiledata; and means for a data store to store an at least one target for theredirector, wherein the data store may dynamically change theredirection to a selected one of the at least one target based at leastin part on the context for the beacon.

Example 42 may be example 41, wherein: the security feature includesmeans for an encoding operation of at least a portion of the beacon datain accord with a cryptosystem; and the security module validates themobile data by at least applying means for a verification operation ofthe cryptosystem that corresponds to the encoding operation.

Example 43 may be example 42, wherein the encoding operation is aselected one of: means for a public key cryptosystem (PKI) signing ofthe at least a portion of the beacon data; or means for a PKI encryptionof the at least a portion of the beacon data.

Example 44 may be any of examples 41-43, in which the beacon dataincludes a first uniform resource locator (URL) broadcast by the beacon,the proxy further comprising: means for a search module to determine ifa second URL is in the mobile data; means for a comparison module todetermine if the second URL corresponds to the first URL; means for adatabase storing at least one known URL associated with at least thebeacon; wherein the context for the beacon includes the second URL beingin the database storing the at least one known URL.

Example 45 may be a physical-web beacon to communicate over a firstnetwork with a mobile machine, to communicate over a second network witha management device, the mobile machine to communicate with a proxy toredirect the mobile machine to a network resource on a second networkbased at least in part on data provided over the first network, thebeacon comprising: means for a first communication interface path tobroadcast a beacon data to the mobile machine over the first network;means for a second communication interface to receive an update from themanagement device over the second network, the update encoded in accordwith a cryptosystem; means for a context analyzer to at least determinea context for the beacon; and means for a security module to at leastvalidate the update from the management device based on the context.

Example 46 may be example 45, wherein the cryptosystem includes anencoding operation that is a selected one of: means for a public keycryptosystem (PKI) signing of the at least a portion of the beacon data;or means for a PKI encryption of the at least a portion of the beacondata.

It will be apparent to those skilled in the art that these examples aresimply exemplary embodiments and other embodiments are contemplated,including other multiple-dependent or means-for variations of the aboveexamples or disclosed embodiments. It also will be apparent to thoseskilled in the art that various modifications and variations can be madein the disclosed embodiments of the disclosed device and associatedmethods without departing from the spirit or scope of the disclosure.Thus, it is intended that the present disclosure covers themodifications and variations of the embodiments disclosed above providedthat the modifications and variations come within the scope of anyclaims and their equivalents.

What is claimed is:
 1. A proxy for at least the physical-web, the proxyto communicate over a first communication path with a mobile machine,the mobile machine at least temporarily to communicate with a beaconbroadcasting beacon data to the mobile machine over a secondcommunication path, the proxy comprising: the first communication pathto receive mobile data from the mobile machine; a security module to atleast validate the mobile data corresponds to the beacon data; a contextanalyzer to validate the mobile data complies with a context for thebeacon; a redirector to send a redirection to the mobile machine basedat least in part on the mobile data; and a data store to store an atleast one target for the redirector, wherein the data store maydynamically change the redirection to a selected one of the at least onetarget based at least in part on the context for the beacon.
 2. Theproxy of claim 1, in which the beacon has an associated securityfeature, wherein the security module validates the mobile data based atleast in part on the security feature.
 3. The proxy of claim 2, wherein:the security feature includes an encoding operation of at least aportion of the beacon data in accord with a cryptosystem; and thesecurity module validates the mobile data by at least applying averification operation of the cryptosystem that corresponds to theencoding operation.
 4. The proxy of claim 3, wherein the encodingoperation is a selected one of: a public key cryptosystem (PKI) signingof the at least a portion of the beacon data; or a PKI encryption of theat least a portion of the beacon data.
 5. The proxy of claim 1, in whichthe beacon data includes a first uniform resource locator (URL)broadcast by the beacon, the proxy further comprising: a search moduleto determine if a second URL is in the mobile data; a comparison moduleto determine if the second URL corresponds to the first URL; a databasestoring at least one known URL associated with at least the beacon;wherein the context for the beacon includes the second URL being in thedatabase storing the at least one known URL.
 6. The proxy of claim 1,wherein the context analyzer validates the beacon data against anexpectation of contact from devices receiving the beacon data.
 7. Theproxy of claim 6, wherein the expectation includes receiving the mobiledata during an in-service time associated with the beacon.
 8. The proxyof claim 1, wherein the redirector selects the redirection from the datastore based at least in part on an event selected from potential eventsassociated with the beacon, the potential events including at least aholiday, or an entertainment event proximate to the beacon.
 9. Aphysical-web beacon to communicate over a first network with a mobilemachine, to communicate over a second network with a management device,the mobile machine to communicate with a proxy to redirect the mobilemachine to a network resource on a second network based at least in parton data provided over the first network, the beacon comprising: a firstcommunication interface path to broadcast a beacon data to the mobilemachine over the first network; a second communication interface toreceive an update from the management device over the second network,the update encoded in accord with a cryptosystem; a context analyzer toat least determine a context for the beacon; and a security module to atleast validate the update from the management device based on thecontext.
 10. The beacon of claim 9, wherein the validate the update isalso based at least in part on the cryptosystem.
 11. The beacon of claim9, wherein the cryptosystem includes an encoding operation that is aselected one of: a public key cryptosystem (PKI) signing of the at leasta portion of the beacon data; or a PKI encryption of the at least aportion of the beacon data.
 12. The beacon of claim 9, wherein thebeacon data includes a first uniform resource locator (URL); and thebeacon data is arranged so as to be parseable by the proxy to facilitatethe proxy to identify the first URL and based thereon to perform theredirect of the mobile machine to a second URL.
 13. The beacon of claim9, wherein the context analyzer may monitor contact with the beaconagainst an expectation of contact from devices, and may log an exceptionif the expectation is not met.
 14. The beacon of claim 13, wherein theexpectation includes whether contact is received during an in-servicetime associated with the beacon.
 15. A method for a proxy to communicateover a first network with a mobile machine, the mobile machine at leasttemporarily to communicate with a beacon for the physical-webbroadcasting beacon data to the mobile machine, the method comprising:receiving the mobile data from the mobile machine; validating the mobiledata corresponds to the beacon data; validating the mobile data complieswith a context for the beacon; dynamically selecting a redirectiontarget from a data store based at least in part on the mobile data andbased at least in part on the context for the beacon; and redirectingthe mobile machine based to the redirection target.
 16. The method ofclaim 15, in which the beacon has an associated security feature, thevalidating the mobile data further comprising: performing the validatingthe mobile data based at least in part on the security feature.
 17. Themethod of claim 17, wherein: the security feature includes an encodingoperation of at least a portion of the beacon data in accord with acryptosystem; and the security module validates the mobile data by atleast applying a verification operation of the cryptosystem thatcorresponds to the encoding operation.
 18. The method of claim 18,wherein the encoding operation is a selected one of: a public keycryptosystem (PKI) signing of the at least a portion of the beacon data;or a PKI encryption of the at least a portion of the beacon data. 19.The method for the proxy of claim 15, in which the beacon data includesa first uniform resource locator (URL) broadcast by the beacon, furthercomprising: searching for a second URL in the mobile data; determiningif the second URL corresponds to the first URL; and validating themobile data satisfies an expectation of contact from the mobile device,wherein the expectation includes receiving the mobile data during anin-service time associated with the beacon.
 20. The method of claim 19,further comprising: setting the redirection target to URL determinedbased on the second URL.
 21. One or more non-transitorycomputer-readable media having instructions for a proxy to communicateover a first network with a mobile machine, the mobile machine at leasttemporarily to communicate with a beacon for the physical-webbroadcasting beacon data to the mobile machine, the instructions toprovide for: receiving the mobile data from the mobile machine;validating the mobile data corresponds to the beacon data; validatingthe mobile data complies with a context for the beacon; dynamicallyselecting a redirection target from a data store based at least in parton the mobile data and based at least in part on the context for thebeacon; and redirecting the mobile machine based to the redirectiontarget.
 22. The one or more non-transitory computer-readable media ofclaim 21 further including instructions to provide for: performing thevalidating the mobile data based at least in part on the securityfeature.
 23. The one or more non-transitory computer-readable mediamethod of claim 22, wherein the instructions for: the security featureincludes further instructions to provide for an encoding operation of atleast a portion of the beacon data in accord with a cryptosystem; andthe security module includes further instructions to provide forvalidating the mobile data by at least applying instructions for averification operation of the cryptosystem that corresponds to theencoding operation.
 24. The one or more non-transitory computer-readablemedia of claim 23, wherein the instructions to provide for the encodingoperation includes instructions to provide for a selected one of: apublic key cryptosystem (PKI) signing of the at least a portion of thebeacon data; or a PKI encryption of the at least a portion of the beacondata.
 25. The one or more non-transitory computer-readable media ofclaim 21, in which the beacon data includes a first uniform resourcelocator (URL) broadcast by the beacon, the instructions for the proxyfurther including instructions to provide for: searching for a secondURL in the mobile data; determining if the second URL corresponds to thefirst URL; validating the mobile data satisfies an expectation ofcontact from the mobile device, wherein the expectation includesreceiving the mobile data during an in-service time associated with thebeacon; and setting the redirection target to URL determined based onthe second URL.